Most of today's computing systems are complex with several different hardware and software components. Further, each of these hardware and software components for each computing system may have different settings or may be manufactured and provided by different vendors from that of another computing system. Also, each computing system may include different versions of the same hardware and software, depending on when they were manufactured. As such, even though a company may purchase all of their computing systems from the same manufacture, each of the individual computers may have varying differences in terms of hardware and software components, as well as the settings associated with these components.
Many companies maintain a computer network consisting of several individual computing systems used by different individuals in the company and managed by an information technology (IT) department. The IT department, in addition to performing general maintenance on the computing systems, will also typically upgrade hardware components and software in the computing systems on a periodic basis. The varying configurations and components of each individual computing system within the network can, however, cause an administrative burden on the maintenance program of an IT department, especially where there are a large number of computing systems in the network.
Desktop Management Interface (DMI) software, now known as System Management Basic Input Output System software (SMBIOS), have been developed to aid system administrators in determining the particular configurations of an individual computing system. Using SMBIOS, the IT department may obtain a wide variety of information concerning the computing system, such as the types of hardware, capabilities, operational status, installation date, etc. Specifically, SMBIOS includes a database of SMBIOS data structures each related to the configuration and components of the computing system. This database typically includes data concerning the computing system from port and slot configurations, processor and memory information, battery and power source indications, to even information concerning chassis configuration.
The information is typically separated into different Type structures, where each Type contains information concerning a certain aspect of the computing system. Currently, there are 128 defined data structure Types in the SMBIOS database that describe various hardware, software, and setting of a computing system. Each Type is further divided into offsets, called Fields, where each Field provides information concerning a particular aspect of the subject component. The data in each Field of each Type may be formatted in a variety of different methods, from simple raw data values to more complex values such as bit fields that provide a wide variety of information based on the individual bit settings.
To interface with this database, SMBIOS requires the use of a utility program. The utility program receives commands from a user and based on these commands, accesses the database and retrieves and displays the desired information from the database to IT personnel. In conventional SMBIOS systems, the database typically only includes the data structures. The information for interpreting and properly displaying these data structures, on the other hand, is typically resident in the source code of the utility program. Specifically, conventional SMBIOS utility programs include all of the strings, field descriptions, bit definitions, etc. hard coded in the utility program for interpreting and displaying the data structures stored in the SMBIOS database.
As an example, the SMBIOS database includes data structure Types which are further organized into data Fields. These Fields may have raw data values indicating information such as memory speed, processor clock speed, etc. To properly display these data Fields when queried by the user, the utility program must not only retrieve the data from the database, but it must also know the data Type's structure, such as whether the current Field data is raw data, a string, bit field, etc. It must also know what format to display the data, (e.g., decimal, binary, hexadecimal, etc.), and provide text describing the data to the user and the units in which the data is displayed.
In a conventional SMBIOS system, all of this information is typically programmed into the source code of the utility program. As such, if the utility is commanded to provide the clock speed of the processor, it will first access the SMBIOS database for this value. The utility will then use definition structures located in the utility program to determine what format the value should be displayed, (for the clock speed it would be decimal), units to display with the value, (Mhz), and text to be displayed to indicate to the user that this value represents the clock speed of the processor.
As with most software programs, the data structures in the SMBIOS database are frequently revised creating new versions of the database. Unfortunately, for each new version of the database, the utility program must also be updated so that data structures in the SMBIOS database can be properly interpreted and displayed. Creating different versions of the utility program is somewhat disadvantageous, as it creates yet another category of differences between individual computing systems. Some computing systems may have one version of the SMBIOS database, while others have a different version. As such, the system administrator must ensure that the proper version of the utility program is installed in the computing system to match the version of the SMBIOS database.
Further, the utility program also includes software code used to operate the utility that is not related to the code used in interpreting and displaying data from the SMBIOS database. As the data used for interpreting and displaying the data in the data structures of the database may be altered for different versions of the SMBIOS database, there is a risk that the non-related code may be overwritten, deleted, or otherwise corrupted during update of the utility program, thereby creating inadvertent bugs in the new version of the utility.